昨天了解方向的章節中，根據數據、資料庫、使用者回饋，團隊提出第一個《選項目標》、「選項聲明」、「解決方案聲明」

我們相信，透過使老師更快、更輕易地開設課程，我們可以將發布課程的比例提高到 50 ％，並將第二門課程的開設數量增加到 30 ％。

接著根據產品形，我們了解方向是《選項目標》、我們再度回到《分析當前狀態》

目前這部分的資訊仍屬於起步階段，課程平台上的課程發行比例僅 25 ％，第二門課大概 10 ％

在《分析當前狀態》這階段，我們繼續問

是什麼阻礙了我們？
-> 我們不夠瞭解課程平台中老師建立課程所遇到的問題
可以採取什麼步驟來更了解？
-> 使用者研究（將安排與 20 明老師訪談一小時）

使用者訪談結束後，經過資料的彙整分析，得出以下幾點

1. 我從其他平台轉移課程時，我希望輕易、準確上傳所有資訊，這樣就不必再花時及重新輸入
2. 創建新課程時，我想輕易輸入所有內容，以便更快速推出
3. 希望平台有純音訊的選項，節省我製作影片時間，也吸引喜歡 podcast 的人成為學生
4. 希望系統提供建議價格的相關資訊，這樣就不用另外花時間去搜尋競品、相似的課程的價格
5. 希望創建課程時，能得知潛在學員想學習的內容是啥，我可以為他們創將相關內容

第一次的訪談結果幾乎包含系統所有的面向，於是團隊決定先畫出個使用者旅程

在使用者旅程中標記一些可能特別有問題的地方，接著提出假設：

我們相信，透過幫助老師輕鬆地、快速地將課程「輸入」系統，可以將課程發布比例提高到 50 ％，並將第二門課程的開設數量增加到 30 ％。

「真正」了解問題 （提醒：使用者測試 跟 可用性測試 不一樣、不應該誤用）

接著書中繼續提到，「真正」了解問題是非常重要的一件事，使用者研究不該被誤解為系統的可用性測試，而是種從使用者角度出發的探索，其背後根本的目的是要「找到你想要解決的問題」

可用性測試則是驗證解決方案是否真正解決問題、是否能被使用者輕易使用

• 使用者測試 -> 生成性
• 可用性測試 -> 評估性

藉由提問來識別出問題真正的痛點是什麼、根本原因是什麼

驗證問題

前面在使用者研究結束後，我們提出假設：幫助老師輕鬆地、快速地將課程「**輸入**」系統 ，這個假設可能也有許多不同、細微差異

比如:

1. 老師輸入的東西都是標準化過的內容嗎？
2. 課程領域這麼多，有辦法讓所有人遵循特定格式嗎？

此時團隊發現仍有尚未解答的疑問，根據此他們才能知道或許老師們希望更有彈性的課程內容，又或是在等待尋求我們的引導。

再度回歸到產品形，最後一步，我們獲得了什麼？我們現在狀態是什麼？
我們理解更多關於老師的問題，他們似乎在內容導入遇到困難，「使用和熟悉系統如何運作」似乎是最大障礙。

那原本的目標是什麼？
-> 透過使老師更快、更輕易地開設課程，我們可以將發布課程的比例提高
現在遇到的障礙是什麼？
-> 如何解決使用者痛點（把內容放入系統、以及釐清什麼東西花費他們製作課程那麼多時間）

看起來還需要更多生成性研究 - 生成性的解決方案研究，必須透過使用者來回答：「他們在解決方案中，最看重什麼」

不只是證明原本的假設 幫助老師輕鬆地、快速地將課程「**輸入**」系統，更是要著重在什麼是好的解決方案。

團隊接著再進行實驗，找 5 位老師，對他們提供一項服務，幫老師（即為使用者）們將課程內容輸入平台，透過實際承擔老師的工作，更理解他們使用的內容是哪些、類型、格式是什麼。

在這次的實驗中，兩週內收到各式各樣的素材，更發現有些老師直接送來毛片（未剪輯過的影音內容），並附上說明，老師將如剪輯。甚至連音訊檔案還是分開的。

團隊成員也因此感到困惑、困擾，因為他們不是剪輯師，也不知道老師竟然會將這些素材存入系統，團隊已告訴過老師必須傳算最終內容過來。

於是乎，透過和使用者再次溝通，團隊發現了老師們遇到的困難不是將課程「**輸入**」系統 而是 創建線上內容（影片）

透過這樣反覆循環的產品形流程，去理解問題、驗證問題，團隊發現了使用者真正的痛點。

於是接著便是要去進行「解決方案探索」

參考資料

1. 跳脫建構陷阱 產品管理如何有效創造價值
2. Escaping the Build Trap by Melissa Perri - Spread Ideas
3. Escaping the Build Trap by Melissa Perri - RODUCTIZED